1. Field of the Invention
The present invention relates to a utilization method and system within a communication network. In particular, the invention relates to a license contract validation method and system within a computer network for web services during runtime.
2. Description of the Related Art
License contracts for web services or other services within a communication network define regulations concerning the services consumption. The license contracts require online status validation during runtime in order to keep track of license contract violations, e.g. exceeding predefined quantities of service consumption. In many cases the license contract may relate to so-called high value/low quantity web services consumption as well as low value/high quantity web service consumption.
A license contract in general is an agreement between two or more contract parties and specifies the license conditions. In particular, the license contract for web services relates to the conditions for the consumption of web services. It defines one or multiple web services, the identity of the requesting contract party which is called as service consumer, optional attributes specifying the service consumption, like rating, price and quality of service and access regulations. Further the license contract may define consumptive policy, concurrent policy, time based policy, named policy and usage condition policy. The consumptive policy may allow only a specified maximum number of requests. The concurrent policy specifies the maximum number of simultaneous requests. The time based policy defines specified times at which the requests are allowed only. The named policy defines, that only identities defined in the contract can request a service. The usage condition policy may contain that the reselling of services is not allowed, for example.
The consumption of a web service is tracked by a metering service which may be an external server component. Each time, when a web service is invoked, the metering service generates meter events. The content of these meter events specifies, among other data, the license contract associated with the consumption of a web service. Typical examples of meter events are the invocation start time (start event), the invocation end time (end event), the invocation trigger (so-called adhoc event) and the cancellation event (cancel event).
The validation and metering of a web service invocation is processed by an array of sequential handlers. These handlers invoke services in order to perform tasks like the identity verification of the service consumer or the license contract validation. A metering handler invokes the metering service in order to process and store the meter events corresponding to the invocation of the web service. The server component which provides these handlers and services is called a service provider. A server component which offers the requested web service is called a service supplier.
If the service consumer initiates a service request, the message context is extracted from a service request massage at the service provider. The message context contains the relevant information of the service request message. While passing the different handlers, the message context is completed. Thereby additional relevant information is inserted to the message context. Each handler may call a service in order to perform defined activities. These services may be external server components. Such an activity may be the verifying of the identity of the service consumer or the providing of contract and license related data, for example.
At the end of the handler chain, the message context contains all data which are required by the metering handler in order to generate an appropriate metering event request. These additional data may be in particular the approved identity, contract data or license data. Every service invocation induces the generation of various meter event requests. These meter event requests are generated by the metering handler and sent to the metering service. The metering service processes these meter event requests. Since the invocations of the metering service are rather slow, the processing of these meter event requests constitutes a severe system performance bottleneck.
The metering handler of the prior art comprises the message context separator, a meter event generator, a cache controller, a cache memory and a metering service invocator.
The message context separator separates the relevant information from the message context, e.g. service request information, identity of the service consumer, contract and license content, and forwards this information to the meter event generator. The meter event generator creates a meter event request which contains the type of the meter event and the information from the message context. Depending on the status of the web service request, examples of the contained meter event types are the start meter event, the end meter event, the invocation meter event and the cancel meter event.
The cache controller receives the generated meter event request and temporarily stores this meter event request within a dedicated cache memory. Usually the cache memory is physically realized by a RAM memory area. The maximum number of meter event requests which can be stored in the cache memory is a fixed coded program parameter. Therefore, the cache memory can hold a fixed and predetermined number of meter event requests. The number of stored meter event requests is monitored by the cache controller. If the maximum number is exceeded, the cache controller reads all stored event requests from the cache, forwards them to the metering service invocator and finally deletes the content of the cache memory. The metering service invocator generates a message which contains the meter event requests and invokes the metering service in order to process the meter event requests.
The caching of the meter event requests is necessary or at least advantageous, since the invocation of the metering service is slow and requires a high amount of network resources. The slow performance of the metering service invocation is mainly caused by the network transaction time. The transaction time is for transmitting the request to the remote metering service and receiving a reply. The slow performance is further caused by encoding and decoding of messages and by the time which the metering service takes to execute.
The metering service generates meter events from the meter event requests, stores these within a database and notifies the license validation component of the contracting service about the updated status of the database.
The license validation component of a contracting service uses the stored meter events in order to calculate and verify that a web service invocation complies with the service access regulations defined in the corresponding license contract. License contracts for web services are based on license models which describe these service access regulations.
An important license model is the consumptive and/or cumulative service access. This regulation implies that a license contract is valid for a predefined quantity. Such a quantity may define, for example, how many consumers may use the web service under a given license contract. A further important license model is the concurrent service access. This regulation defines the boundaries regarding how many simultaneous service invocations are allowed.
For license contract validation, the license contract validation component invokes the metering service in order to receive the stored meter events which correspond to the license contract. The license contracts, which define regulations concerning accumulation and concurrence of web services consumption, require online status validation during runtime in order to keep track of license contract violations, e.g. the exceeding of predefined quantities of service consumption. The exceeding predefined license contract limits during runtime typically implies business consequences like extra costs, violation fees or even service exclusions.
Since the metering handler stores the meter event requests the cache memory, there is no guarantee that the persistence facility, e.g. database, maintained by the metering service represents the true status of the business service consumption at that point in time when the business service is requested.
Therefore, possible web service consumption violations are only detected after the cache memory has been flushed to the database. This point in time may be well after the time when the service has been requested. This delayed violation detection may imply severe consequences. Service suppliers are not able to detect overload of recourses in the moment of its occurrence. The service consumer is faced with extra costs due to violating consumptive and/or concurrent service access limitations and therefore unpredictable business impacts. Due to the fixed coded caching strategy of the metering handler, the service provider can not adapt the caching of the meter event requests to the needs of the individual contracts.